There exists considerable interest in using packet-based rather than circuit-based bearer transport mechanisms in telecommunications networks to carry user data, for example, voice traffic. The reasons for this are related both to improvements in efficiency as well as potential cost savings. Much consideration has been given for example to the use of Internet Protocol (IP) networks to transport user information between network nodes. IP networks have the advantage that they make efficient use of transmission resources by using packet switching and are relatively low in cost due to the widespread use of the technology (as opposed to specialised or proprietary communication technology). There is also interest in using other transport mechanisms including AAL1/2/5, FR etc.
The standard ISUP which deals with the setting-up and control of call connections in a telecommunications network is closely linked to circuit-based bearer transport mechanisms and does not readily lend itself to use with packet based transport technologies such as IP and AAL2. As such, several standardisation bodies including the ITU-T, ETSI, and ANSI, have considered the specification of a protocol for the control of calls, which is independent of the underlying transport mechanism. This can be viewed as separating out from the protocol, Bearer Control functions which relate merely to establishing the parameters (including the start and end points) of the “pipe” via which user plane data is transported between nodes, and which are specific to the bearer transport mechanism. The new protocol, referred to as Bearer Independent Call Control (BICC), retains Call Control functions such as the services invoked for a call between given calling and called parties (e.g. call forwarding), and the overall routing of user plane data. FIG. 1a illustrates the conventional integrated Call Control and Bearer Control structure of ISUP whilst FIG. 1b illustrates the proposed new separated structure. It is noted that at the junctions between different bearer networks, i.e. between different transport media, a gateway node is present which requires both the Call Control (CC) functions and Bearer Control (BC) functions. This node is referred to as a gateway node.
As a result of the CC/BC split, a new interface is exposed between the CC functions and BC functions. A protocol is required to enable coupling between the CC functions and BC functions when a node is implemented in a separated environment. One such interface protocol is the ‘Media Gateway Control Protocol’ (MGCP) whilst another, developed by IETF MEGACO group, is identified as H.248. According to H.248, the CC function is known as the ‘Media Gateway Controller (MGC)’ and the BC function is known as the ‘Media Gateway (MG)’. The MGC and MG are sometimes referred to as the Call Serving Function (CSF) and Bearer Interworking Function (BIWF) respectively, with the MGC being responsible for call control signalling (e.g. ISUP, BICC, H.225, SIP, etc) and the MG being responsible for termination of the physical bearer(s) associated with a call's user plane data (e.g. TDM circuit, RTP stream, AAL2 channels, etc). Bearer Control such as Q.AAL2, IPBCP, and SDP may be implemented in either the MG or the MGC.
The need for the MGCP is illustrated in FIG. 2, which illustrates two peer gateway nodes which communicate with one another at both the CC level (MGC) and the BC level (MG). H.248 describes resources available at the bearer level in the MG (e.g. inputs, outputs, connectivity, call processing etc) in terms of “contexts” and “terminations”. A context, identified by a context ID, is a logical concept embodied in a data structure stored at the BC and/or CC level which defines a connection within the BC functions using at least one termination. A termination represents a physical endpoint to which a bearer is physically or logically connected, and can be assigned one of a number of physical characteristics, for example transport type (Circuit, IP, ATM), media or codec type (GSM, G.711), or a priority level. FIG. 3 illustrates a simple context 1 having two terminations T1 and T2. This could represent, for example, a traditional telecommunications speech call between two parties where T1 represents the input port or incoming circuit for the calling party to the BC layer and T2 represents the output port or outgoing circuit for the called party from the BC layer.
WO01/49045 describes a telecommunications system in which a split exists between the call control and bearer control levels. This document is concerned in particular with the routing of call control related data from a traditional SS7 signalling network to a network having the split architecture.
ITU-T has developed a profile for the use of the core H.248 protocol, H.248.1, in BICC based networks. This is contained in recommendation Q.1950, “Bearer independent call bearer control protocol”. That document effectively profiles H.248,1 and, indicates which extensions are to be supported. In depth procedures are documented for call related and non-call related scenarios and the document provides a linkage to the BICC procedures defined in Q.1902.4. For mobile networks, the 3GPP have also produced profile documentation for the use of H.248.1 across the Media Gateway Controller—Media Gateway interface. Technical Specification 29.232, “Media Gateway Controller (MGC)—Media Gateway (MGW) Interface; Stage 3”, details this profile. TS 29.232 provides the same level of detail as Q.1950. The following discussion concerns modifications and additions to Q.1950 and TS 29.232 which will in turn result in the specification of new packages for H.248.
A decomposed switching (or gateway) node must support generic telecommunication services. In particular; a switching gateway must support multiplex connections where a number of circuits are multiplexed together, e.g. to provide a subscriber or other user with a high bandwidth connection, in particular to allow the high speed transmission of data, audio, and video. Such multiplexed connections are commonly used in today's ISUP-based circuit switched networks and the service is referred to as an N*64K service (where N identifies the number of (ISUP controlled) circuits multiplexed to form the connection and 64K is the data rate of a single circuit). FIG. 4 illustrates schematically the multiplexing of four 64K circuits to provide a connection with an effective bandwidth of 256K. Definitions of the N*64K service are given in:                ITU-T Recommendation Q.763 (12/1999), Signalling System No. 7—ISDN user parts formats and codes, and        ITU-T Recommendation Q.764 (12/1999), Signalling System No. 7—ISDN user part signalling procedures.        
In a N*64K connection, it is necessary for the Media Gateway to receive data from a set of “incoming” circuits in the correct order and to output that data on a set of “outgoing” circuits also in the correct order. The circuits on either side may be contiguous (i.e. consecutive), or may be non-contiguous. Moreover, the order of the circuits on the two sides may differ. For example, the circuit order on the incoming side may be CIC1, CIC2, CIC3, whilst on the outgoing side the order may be CIC1, CIC3, C!C2. The Media Gateway must generate, or obtain, a circuit assignment map in order to correctly handle multiplex connections.
A problem with implementing support for multiplex connections is that the necessary functionality must be distributed between the MGC and the MG. As communication between these two entities depends upon existing gateway control protocols, the scope and flexibility of the service depends upon the chosen protocol. The H.248 core protocol (H.248.1) specifies a command message structure, for messages sent from the MGC to the MG. An example command message for achieving a multiplex is as follows:
MessageTransaction{Context{Command [ADD]{Termination [TID=1]{DescriptorsRemoteDescriptor,[Package/property=x,....]MultiplexDescriptor [Mux=....]}}}}
According to H.248.1 the type parameter (Mux) of the Multiplex Descriptor field is statically defined as one of the following enumerations; H.221, H.223, H.226, and V.76. By default, with H.248, all data arriving on each of the specified terminations of the specified context is output onto all of the other terminations, i.e. a fully meshed connection. This “conference” configuration is illustrated schematically in FIG. 5. Setting the Mux type parameter to a particular static type, e.g. H.221, will result in this behaviour being modified in that the data received on the terminations specified in the multiplex will be output to those not specified in the multiplex. However, for the N×64K service, data received from the multiplex must be output to the other terminations in a certain order. The multiplex descriptor of the current H.248 protocol does not allow this order to be indicated and thus the current H.248 cannot support the N*64K service.